1. Field of the Invention
The present invention generally relates to processing of an object in a computer processing system and, more particularly, to processing in which an object allocated to a stack is copied to a heap.
2. Related Art
Conventionally, in a processing system such as one based on Java®, an object generated in a method upon calling of the method and no longer used after the completion of the processing of the method can be allocated on a stack of the processing thread. However, if methods are frequently called such as through recursive calls, the stack area can be used up to cause stack overflow. As such, a process of reducing the stack size is performed by copying an object in the stack area into a heap and shifting stack frames.
In another case, in a work stealing process in the Fork-Join framework of Java®, a task object generated in a method can be allowed to be processed by other threads to ensure that the process waits until the completion of the processing of the task object. In this case, the task object can be placed on the stack. Here, if a thread other than a thread that has generated the task object will process the task object, a process of copying the task object from the stack into the heap is necessary before processing of the task for safety of the processing system.
Such a process in which an object allocated to the stack is allocated to the heap will be referred to as heapification. Hereinafter, for convenience, an object allocated on a stack will be referred to as a stack object, and an object copied from a stack to the heap will be referred to as a heapified object.
However, the process is not completed simply by copying the object from the stack into the heap. It is necessary to make the other stack objects correctly point to the copied heapified object. A series of process steps for this purpose will be described with reference to FIGS. 1 to 3.
FIG. 1 shows a stack 102 and a heap 104 in computer memory. The stack 102 includes stack frames 102a, 102b, etc., each corresponding to a method call in a thread.
As shown, a stack object 106 and a local variable 108 are placed in the stack frame 102a, and a stack object 112 with a field variable 112a is placed in the stack frame 102b. 
For example, the arrangement of the stack objects and the variables as in FIG. 1 corresponds to a state in the following code in which “bar” is being processed upon request of processing of “foo”.
class S {}class T {S a;}void foo ( ) {S a = new S ( );bar (a);}void bar (S a) {T b = new T ( );b.a = a;...}
Now, it is assumed that, through functionality of a Java® Virtual Machine or an operating system, the stack object 106 is copied into the heap 104 to become a heapified object 202, as shown in FIG. 2.
Then, when the address of the heapified object 202 is an address B, the heapification requires that an address A that has pointed to the stack object 106 in the stack frames be rewritten to the address B, as shown in FIG. 3.
For this purpose, the Java® Virtual Machine or the operating system should perform a process of sequentially scanning the stack frames to rewrite variables pointing to the address A of the original stack object 106 to point to the address B of the heapified object 202. Since it is not known which stack frames include variables pointing to the address of the unheapified stack object, all stack objects need to be scanned, which is a process requiring long time.
A technique disclosed in Erik Corry, “Optimistic stack allocation for java-like languages”, International Symposium on Memory Management archive, Proceedings of the 5th international symposium on Memory management table of contents, Ottawa, Ontario, Canada, Pages: 162-173, 2006 involves temporarily allocating an object to the stack, and upon escaping, copying the object into the heap. In this technique, the stack is configured on a loop basis rather than on a method frame basis, and loop areas called after an area to which the object is allocated are scanned to reestablish references.
Also in a technique disclosed in Kevin Cleereman, Michelle Cheatham, “Runtime Support of Speculative Optimization for Offline Escape Analysis”, (http://knoesis.wright.edu/library/publications/SERP-07-EscapeAnalysis.pdf), only frames above a stack frame to which an object is allocated are scanned.
However, the above conventional art does not disclose techniques of reducing the time it takes to scan stack frames.